mojira.dev

[Mojang] Tomas Alaeus

Assigned

No issues.

Reported

No issues.

Comments

The bug isn't on the radar anymore because the bug was fixed (the one we successfully reproduced at least). The cause is very messy though and I'm not surprised there are still issues left with it, or new issues that appear afterwards.

 

I'll reopen the bug on the internal tracker.

We found the cause of this and a fix will be available for the next update.

What does the db folder contain? Is it lots of log-files along with the ldb files? That's how it should look if the backup command is permanent on, because leveldb is told not to delete any files. Maybe the log files are only kept from the time where the backup is active?

If that's the case then I don't understand what's going on... When the world has grown really large, try to restart the server. That usually makes leveldb do a garbage collection and clean up it's files (more or less what your Universal Minecraft Editor does).

 

Could it be your script that's holding on to some file locks even after the backup is finished?

That sounds like the `save resume` command wasn't executed properly. Does the server respond with an error to the resume command? Does the second hold command succeed?

The old files will get cleaned up eventually when leveldb figures out that it can remove them. Are you saying that the extra size isn't reduced automatically after a while?

Acknowledged.

The gamemode setting in server.properties is currently only used for the default gamemode when the world is created the first time. We'll change this in some way.

@unknown: Having two different ports works without problem. The bug here is only about what is printed to the console. When reading the console you should ignore the second printout.

We don't support this scenario. Lifeboat and other third party servers handles this in other ways.

We see no need to implement such a feature. The server automatically saves all data to disk when needed. If you explicitly want to force a save you could use the backup commands "/save hold" and "/save resume".

Good news: We have a potential fix for this issue. The world have been slightly corrupted but we've found a way that might work.

Sad news: The fix is risky and will probably not have enough time to be tested for the upcoming release. That means that it won't be release until later (probably June).

@unknown: The fixed world should have been uploaded now, and some days should have been added to it. I hope it works for you now.

We haven't found a solution for this yet. We're partly working on it at the same time as we're fixing some bigger issues with how players are saved.

@unknown: Repair means just that. We don't know what causes the corruption, but we have some ideas on how to make it try to autorepair if a corruption occurs.

@unknown: We've had a long weekend which is why nothing have happened the last few days.

While your Realm experienced similar issues as the other (REALMS-945) it wasn't as easy to repair it. We're still working on it though.

@unknown We have uploaded a fixed version of your Realm. Hopefully it works for you now.
@unknown We're going to upload a fixed version of your Realm soon.

We're working on adding compensation days to your Realms, hang on.

We're investigating it at the moment.

It's virtual servers. It probably doesn't have anything to do with the disks. But yes, something in our code is probably stopping the game from saving.

We have now successfully reproduced the issue.

Thanks a lot for the report, and sorry for the very late replies.

I'm closing it as fixed because you said the issue disappeared. If you still have problems with it we can reopen it.